IBIS Macromodel Task Group Meeting date: 24 October 2017 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad noted that he would like to discuss BIRD165 and give a review of it, time permitting. ------------- Review of ARs: - Mike LaBonte to notify the Open Forum about the minor edits to BIRD158.6 Background Information. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Walter: Motion to approve the minutes. - Dan: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: BIRD189: - Arpad: To recap from last week, we now have a version [draft 10] that captures the consensus of Bob and Walter and others. - We wanted to give Radek a chance to address that draft. - Radek: What we have now should be enhanced with what I emailed to the group on October 4th. - The choices of "Open" and "Reference" should probably be extended to include the option to provide the actual values of the terminating resistances per port. - [Arpad sharing Radek's email] - Options I suggested were: - Open - Common (model maker specifies a single impedance) - Per_port (model maker specifies an impedance for each port) - Reference (use value(s) from the Touchstone file). - I think this is more comprehensive. - Bob: We have diametrically opposed views. - One position has been, provide no guidance, let the EDA tool do what's best for the given simulation. - Middle ground was to have the two options (Open, Reference) along with a statement that the EDA tool can override these options and tune unused port settings for the actual simulation being performed. - Or we can add several more parameters, make the syntax more complicated, and allow the model maker to explicitly declare how each unused port should be terminated. The model maker would be specifying certain things whether or not they even know exactly how it's being used. I'm uncomfortable going with such detail. - Radek: The EDA tool has absolutely no knowledge about what's going on when the model maker provides Touchstone data with more ports than are needed. - It's really up to the model maker to tell everyone what to do with those unused ports. - In some cases the user may have some input, and that is the only way the EDA tool could have any additional information and act upon it. - The "Reference" is not necessarily the right answer. It could be a 75 Ohm line and the data may be normalized to 50 Ohm. Even worse, the Reference could be 0.1 Ohms, when it's actually .01 Ohms on a particular port, and the difference is a reflection of .8 or .9. - Only the model maker can tell you why they are providing Touchstone data with many more ports than are needed for the specific use. - Bob: The model maker has no idea how the model will be used. They just provide the data and a reference impedance. It's not the model maker's business how it's ultimately used. - If you have an s100p, that's technically the correct information. Is it even valid to specify what to do with unused terminals? - Radek: Unless we expose all the Touchstone ports completely (no unused ports), which we don't want to do, then we must provide a way for the model maker to explain why the Touchstone data has more ports than are used in the particular model and how to handle it properly. - My point is that you have to provide the model maker with better options. - Note that this is still not complete since we only allow purely resistive terminations. - But if we let the model maker specify the proper terminations then they can wrap the Touchstone data into a model with fewer ports. - If those terminals in an s100p are unconnected (not exposed by the model), then you have no idea what any actual connections to a board would be. Either we can leave unconnected ports open, or give some other options to the model maker. - Walter: Unused_port_termination mode is not an option for the EDA tool, it is set by the model maker. - The EDA tool can override it, but the model maker says what to do. - I think the two additional options Radek proposes are unnecessary, but they don't hurt anything. - The only thing I don't like about Radek's proposal is the default of "Open". I think the Unused_port_termination should be required, and the model maker can specify "Open" if that's what they want. - Radek: I disagree with calling them unnecessary. We are giving the model makers more options to express what they know. - Walter: As long as we make the parameter required, I'm okay with adding the two options. It will just be a bit more work for the parser developers. - Arpad: Do we have a final solution now? - Walter: The solution is make the parameter required and add Radek's two options. - The important option for me is to be able to set it to "Reference." - I think the other options are superfluous and don't expect I'll see many models using them, but I'm okay with that. - The addition of the two options would not affect the current text of the BIRD as it relates to "Open" and "Reference". - Bob: I'm not in favor of adding the two new options. - It's going way too far. It's a syntactical addition of yet another subparameter so we could list the impedances per port. - It's a lot of additional work for the parser, and I'm not sure it's information the model maker even has. I'm not sure it's technically correct. - Walter: I suggest we have Radek take Bob's current draft and create an alternate section that includes his two additional options. - Then we can review both and debate it and possibly resolve it with a vote if Bob and Radek can't come to agreement. - Arpad: Radek, can you do that in time for tomorrow's Interconnect Meeting? - Radek: I will send it out tonight. BIRD 165: Parameter Passing Improvements for [External Circuit]s - Arpad: The problem I was trying to address with this BIRD is this: - We added parameter passing capabilities for the [External Model]s and [External Circuit]s. Originally we only listed the parameter names, and theoretically the EDA tool was to come up with a way to pass them values that the user wanted to provide. But I haven't seen anybody doing it that way. - In IBIS 6.0 we added the capability of specifying parameter values within an IBIS file (BIRD160.1). - That works well, but I've realized that there's an issue in the [External Circuit] case. We instantiate [External Circuit]s with a [Circuit Call]. The same [External Circuit] could be instantiated multiple times. The biggest benefit of parameter passing is providing different values to different instances. But since we only added parameter value assignment to the [External Circuit] syntax, every instance of that circuit would get the same values. - This BIRD address that by adding the same parameter passing syntax to the [Circuit Call]. Every [Circuit Call] could thus provide different parameter values to the [External Circuit]. - I don't think this is critical for 7.0, but if no one is opposed I'll put it on next week's agenda. - I think it should not be difficult. - Walter: Do you have an example of this so we can look at it? - Arpad: There are no examples in the BIRD yet, but I will add some. - Bob: I'm fine with it being on the agenda. - Radek: This is just fixing the instantiation. I think it is probably the right thing to do. I think it's possible to get it into 7.0. Question about Section 10.2.2.3.2, Time Domain Simulation Reference Flow: - Discussion: Arpad asked a question about this sentence: "However, when the Tx AMI model contains an AMI_GetWave function that performs a similar or better equalization than the Tx AMI_Init function, there is a possibility for double-counting the equalization effects in the Tx executable model file." Arpad asked how a Tx's AMI_GetWave() function could do any optimization or adaptation at all, since the input to the Tx is just the ideal bit pattern waveform. Walter said that the AMI_Init() function might pass the IR information to the AMI_GetWave(). Arpad questioned whether this was legal. Walter noted that it might not be the best thing to do, but that the spec. didn't prohibit it. Ultimately the group noted that "better equalization" was not to be understood as "better optimization," and the consensus was that the text is okay as currently written. - Curtis: Motion to adjourn. - Mike L.: Second. - Arpad: Thank you all for joining. AR: Radek to produce a new draft of BIRD189.5 containing his two additional options for Unused_port_termination(s). ------------- Next meeting: 31 October 2017 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives